ALB のスティッキーセッションで固定できるパターン・できないパターンを図にしてみた

ALB のスティッキーセッションを利用したアプリケーションを検討する際に、まずは想定するパターンが実現可能かどうかを確認しましょう。

AWSテクニカルサポートノート

#Application Load Balancer（ALB）

#Elastic Load Balancing (ELB)

#テクニカルサポート

#AWS

M.Shimizu

2024.01.10

はじめに

アノテーションテクニカルサポートのShimizuです。

ALB でステートフルなアプリケーションを構築する際、同じクライアントからのリクエストを ALB 配下の同じサーバーへ固定して転送する「維持設定（スティッキーセッション）」の利用を検討するケースは多いと思います。弊社サポートデスクへも、よくお問い合わせをいただきます。

しかしながら、スティッキーセッションはターゲットグループレベルで動作する機能のため、もしサーバーを多段に経由するようなアプリケーションを検討している場合、まずはスティッキーセッションの機能で実現可能かどうかを確認することが大事です。（参考1）

そこで今回は、実際にお問い合わせがあった構成例をもとに「スティッキーセッションで固定できるパターン・できないパターン」を図にしてみました。

スティッキーセッションで固定できるパターン

まずは一般的な OK のパターンです。
下記の図1のように単一のターゲットグループ配下にサーバーA・Bがあった場合、スティッキーセッションを有効化することで、例えばクライアントAからのリクエストはサーバーAへ、クライアントBからのリクエストはサーバーBへ、というように固定できます。

図1:OKパターン

スティッキーセッションで固定できないパターン

NGパターン1:サーバーを複数経由する多階層の構成

下記の図2のように、サーバーA・Bの下の階層にさらにサーバーC・Dがあったとします。

この場合、スティッキーセッションを有効化することでターゲットグループ直下のサーバーAまではリクエストが固定されますが、その下の階層についてはスティッキーセッションの効果が及ばないため、サーバーC・Dのどちらに転送されるかは固定できません。

図2：NGパターン1（多階層の構成）

NGパターン2:複数のターゲットグループにまたがる構成

下記の図3のように、リクエストパスによってターゲットグループ1と2に分かれ、それぞれのターゲットグループから同じサーバーに負荷分散する構成があったとします。

この構成でスティッキーセッションを有効化すると、ターゲットグループ1・2でそれぞれ個別にスティッキーセッションが働き、サーバーA・Bのどちらかには固定されますが、「ターゲットグループ1とターゲットグループ2で、同じサーバーに固定する」という動作は保証されません。

例えばターゲットグループ1ではサーバーAに固定され、ターゲットグループ2ではサーバーBに固定される、という可能性もあります。

図3:NGパターン2（複数のターゲットグループにまたがる構成）

ALB のスティッキーセッションで固定できない場合の代替案は？

主に考えられる代替案としては、以下の2通りがあります。

「アプリケーションベースの維持」で実現できないか検討する

スティッキーセッションには、ALB が生成した Cookie を利用する「期間ベースの維持」に対し、ユーザーがアプリケーション側で定義した Cookie を利用する「アプリケーションベースの維持」があります。（参考1）
ユーザー独自の Cookie を利用することで、期間ベースの維持と比較して柔軟な設定が期待できます。

ただし冒頭で述べた通り、スティッキーセッションはあくまでもターゲットグループレベルで動作する機能であるため、アプリケーションベースの維持を利用しても、複数のサーバーやターゲットグループを経由するような構成では、想定通りに動作しない可能性があります。

セッション情報をサーバーに保存しない構成（ステートレスな構成）を検討する

サーバー上にセッション情報を保持せず、外部のDBなどにセッション情報を保持して読み込む構成（ステートレス構成）にすることが考えられます。（参考2）

アプリケーションの大幅な仕様変更が必要にはなりますが、ステートレスな構成にすることでリクエストを同じサーバーに固定する必要がないため、スティッキーセッションの制約に縛られず柔軟な構成が可能になります。

スティッキーセッションが機能しているか不明な場合は？

もし上記例のような多段構成ではないにも関わらず、スティッキーセッションが機能していない、と思われた場合は、まず下記のトラブルシューティング記事を確認しましょう。

Application Load Balancer のセッション維持機能のトラブルシューティング | AWS re:Post

記事に記載のように、リクエストに AWSALB という名称の Cookie が含まれるかを確認したり、ALB アクセスログを調べて同じ送信元IPアドレスからのリクエストが同じターゲットEC2に転送されているか、といった観点から調査することが可能です。

さいごに

いかがでしたでしょうか。

弊社ヘルプデスクに「スティッキーセッションを前提に構築したアプリケーションで、想定通りにリクエストを固定できない」というお問い合わせをよくいただきますが、調査を進めてみると、前述のNG例のように多階層の構成になっていることが少なからずあります。
ある程度アプリケーションの構築を進めた段階で「そもそもスティッキーセッションでは実現できない」ということが判明すると、あとから大幅な構成変更が必要になってしまう事態になりかねません。

本記事は上記のような事態を回避し、アプリケーションの設計段階でスティッキーセッションの採用可否を判断する材料になれば、との思いで執筆しました。

この情報がどなたかのお役に立てば幸いです！

参考資料

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。